Re-opening Closures

There are two different commonly-used evaluation methods for functional languages: normal-order graph reduction, and call-by-value execution of closure code. The former is usually more expensive per operation, but has the capability of partially evaluating functions before they are applied. The latter method usually leads to faster execution — and is thus used in most compilers — but can’t ‘‘optimize’’ functions before they are called. The different advantages of the two methods are particularly visible in the evaluation of higher-order functions. After a higher-order function is applied to one argument, the graph-reducer can begin evaluation, while the closure-code evaluator must wait until all arguments are present. On the other hand, because the closure-code evaluator executes the native code of the computer, it usually outperforms the graph-reducer. The two evaluation algorithms can be combined to take advantage of the best behaviors of both. Fragments from programs that are already executing can be extracted, reduced, and re-compiled. This is done with an operator, reduce, that is semantically transparent: — reduce( f ) does not change the behaviour of the program fragment f, but can make f much more efficient. This applies not just to functions f in the original program, but to functions constructed at runtime. 1. Higher-order functions The notion of a higher-order function (a function that returns another function as a result) is present in many functional languages, but it is often found in conventional languages as well. For example, the C programming language has no built-in notion of higher-order functions, but there are many softwaredevelopment tools (like the parser generator YACC[1]) that produce C programs as their output. It is inconvenient, inefficient, and ugly to implement higher-order functions by producing source code; so the very fact that it has been done repeatedly shows how important higher-order functions are. Functional languages based on lambda-calculus have an inherent notion of higher-order function, so that they may be programmed in the language directly, without resorting to the output of source code to be fed back into the compiler. This is a great advantage, since now functions like parser generators can be implemented as a higher-order function completely inside the language, perhaps with the type: PG: Grammar → (String → ParseTree) The parser-generator PG can then be applied to a grammar, yielding a parser P : P = PG(MyGrammar) This step may take a nontrivial amount of time, as it involves the construction of parsing tables. Once it is done, however, the parser P may be applied to many different input strings, without executing PG for each one.